*****************BEGIN
OF CHANGE
*****************
The present document describes the architecture and functional requirements within a Third Generation Mobile Communication System (3GPP MS).
The specification shows the service requirements from a Law Enforcement point of view only. The aim of this document is to define a 3GPP MS interception system that supports a number of regional interception regulations, but these regulations are not repeated here as they vary. Regional interception requirements shall be met in using specific (regional) mediation functions allowing only required information to be transported.
The handover interfaces for Lawful Interception (LI) of
Packet-Data Services, Circuit Switched Services, and Multimedia Services
within the UMTS network for
Sstage
3 are described in 3GPP TS 33.108 [11].
*****************NEXT CHANGE*****************
The following figures contain the reference configuration for the lawful interception. The circuit-switched configuration is shown in figure 1a. The packet-switched configuration is shown in figure 1b. Intercept configurations for HLR and IMS are shown in figures 1c and 1d. The WLAN interworking configuration is shown in figure 1e. The various entities and interfaces are described in more detail in the succeeding clauses.
PS domain of the UMTS system (GSN and Multimedia Packet
Data services) and 3GPP-WLAN interworking network provide UMTS/GSM
customer’s mobile equipment (UE) with connectivity service to another
end of the communication. Another end of the communication may be a network
element (server) or another UE. Therefore, UMTS system provides IP layer
[15] services. Hence, UMTS NO/AP is responsible only for IP layer interception
of CC data. In addition to CC data, the LI solution for UMTS offers generation
of IRI records from respective control plane (signalling) messages. The IP
layer connectivity service is needed to support application layer [16] service
provision to UMTS/GSM customers. For instance, the following are examples
of application layer services: email service; web browsing
service;,
FTP
service;,
audio services (e.g. VoIP,
PoC);,
other multimedia services (MBMS, video
telephony);,
etc.
The
Mmajority
of the application layer services require addition of respective server
functionality to the network. Note that it is not necessary that such application
layer SP should be the same commercial entity as the UMTS AP/NO in question.
NOTE 1: For instance in MBMS a BM-SC and especially content providing server may be operated by different commercial entity than UMTS network.
Figure 1a: Circuit switched intercept configuration
Figure 1b: Packet Switched Intercept
configuration
Figure 1c: HLR Intercept
configuration
Figure 1d: IMS-CSCF Intercept configuration
Figure 1e: WLAN Interworking Intercept configuration
The reference configuration is only a logical representation
of the entities involved in lawful interception and does not mandate separate
physical entities.
This
allows for higher levels of integration.
Regional Mediation Functions, which may be transparent or part of the administration and delivery functions, are used to convert information on the HI1, HI2 and HI3 interfaces in the format described in various national or regional specifications. For example, if ES 201 671 [3] or J-STD-025 [8] is used, then the adaptation to HI1, HI2 and HI3 will be as defined in those specifications.
There is one Administration Function (ADMF) in the network. Together with the delivery functions it is used to hide from the 3G ICEs that there might be multiple activations by different Law Enforcement Agencies (LEAs) on the same target. The administration function may be partitioned to ensure separation of the provisioning data from different agencies.
See the remaining clauses of this document for definitions of the X1_1, X1_2, X1_3, X2 and X3 interfaces.
Interception at the Gateways is a national option.
In figure 1a DF3 is responsible for two primary functions:
- Call Control (Signalling) for the Content of Communication (CC); and
- Bearer Transport for the CC.
HI3 is the interface towards the LEMF. It must be able to handle the signalling and the bearer transport for CC.
In figures 1a, 1b and 1e, the HI2 and HI3-interfaces represent the interfaces between the LEA and two delivery functions. The delivery functions are used:
- to distribute the Intercept Related Information (IRI) to the relevant LEA(s) via HI2 (based on IAs, if defined);
- to distribute the Content of Communication (CC) to the relevant LEA(s) via HI3 (based on IAs, if defined).
In figures 1c and 1d the HI2 interface represents the interface between the LEA and the delivery function. The delivery function is used to distribute the Intercept Related Information (IRI) to the relevant LEA(s) via HI2.
NOTE 2: With reference to figure 1c, CC interception does not apply to HLR.
NOTE 3: For IMS, figure 1d relates to the provision of IRI for SIP messages handled by the CSCF. Interception of CC for this case can be done at the GSN under a separate activation and invocation, according to the architecture in Figure 1b (see also clause 7.A.1).
*****************NEXT
CHANGE*****************
5.1.1 X1_1-interface
The messages sent from the ADMF to the 3G ICEs (X1_1-interface) contain the:
- target identities (MSISDN, IMSI, IMEI, SIP URI or TEL URL, NAI) (see notes 4, 5, 6);
- information whether the Content of Communication (CC) shall be provided (see note 1);
- address of Delivery Function 2 (DF2) for the intercept related information (see note 2);
- address of Delivery Function 3 (DF3) for the intercepted content of communications (see note 3);
- IA in the case of location dependent interception.
NOTE 1:
As an option, the filtering whether intercept
productcontent
of
communications
and/or intercept related information has to
be provided can be part of the delivery functions. (Note that intercept
product
content
of communications options do not apply at the CSCF, HLR and
AAA server). If the option is used, the corresponding information can be
omitted on the X1_1-interface, while "information not present" means "intercept
content
of
communicationsproduct and related information
has to be provided" for
the
ICE. Furthermore the delivery function which is not requested
has to be "pseudo-activated", in order to prevent error cases at
invocation.
NOTE 2: As an option, only a single DF2 is used by and known to every 3G ICE. In this case the address of DF2 can be omitted.
NOTE 3: As an option, only a single DF3 is used by and known to every 3G ICE (except at the CSCFs, HLR and AAA server). In this case the address of DF3 can be omitted.
NOTE 4: Since the IMEI is not available, interception based on IMEI is not applicable at the 3G Gateway. Moreover, in case the IMEI is not available, interception based on IMEI is not applicable at 3G ICEs.
NOTE 5: Interception at the CSCFs is based upon either SIP URI or TEL URL. SIP URI and TEL URL as target identities are not supported by the other ICEs.
NOTE 6: Interception based on NAI is only applicable at AAA server and PDG. As the NAI could be encrypted or based on temporary identity at the PDG, interception based on the NAI is not applicable in those cases in that node.
NOTE 7: Void
If after activation
subsequently
Content of Communications (CC) or Intercept Related Information (IRI) has
to be activated (or deactivated) an "activation change request" with the
same identity of the target is to be sent.
Figure 3: Information flow on X1_1-interface for Lawful Interception activation
Interception of a target can be activated on request from different LEAs and each LEA may request interception via a different identity. In this case, each target identity on which to intercept will need to be sent via separate activation messages from ADMF to the 3G ICEs on the X1_1-interface. Each activation can be for IRI only, or both CC and IRI.
When several LEAs request activation on the same identity
andthen
the ADMF determines that there
areis
an existing
activations
on the
identity.
In this case, the ADMF may (as an implementation option)
send
an additional activation
message(s)
to the 3G ICEs. When the activation needs to change from IRI only to
CC and IRI an activation change message will be sent to the
3G ICEs.
In the case of a secondary interception activation only the relevant LEAs will get the relevant IRIs.
*****************NEXT
CHANGE*****************
.
5.2.2
X1_2-interface
(IRI)
The message(s) sent from the ADMF to Delivery Function 2 for the deactivation of the Intercept Related Information contains:
- a DF2 activation ID, which uniquely identifies the activation to be deactivated for DF2.
If a target is intercepted by several LEAs and/or several identities simultaneously, a single deactivation is necessary for each combination of LEA and identity.
Figure 7: Information flow on X1_2-interface for Lawful Interception deactivation
5.2.3
X1_3-interface
(CC)
For
the deactivating the delivery of the CC the
message(s)
sent from the ADMF to DF3
contains:
- a DF3 activation ID, which uniquely identifies the activation to be deactivated for DF3.
Figure 8: Information flow on X1_3-interface for Lawful Interception deactivation
*****************NEXT
CHANGE*****************
Figure 11 shows an extraction from the reference configuration in figure 1a which is relevant for the invocation of the lawful interception.
Figure 11: Functional model for Lawful Interception invocation
The HI2 and HI3 interfaces represent the interfaces between the LEMF and two delivery functions. Both interfaces are subject to national requirements. They are included for completeness, but are beyond the scope of standardization in this document. The delivery functions are used:
- to convert the information on the X2-interface to the corresponding information on the HI2-interface;
- to convert the information on the X3-interface to the corresponding information on the HI3-interface;
- to distribute the intercept related information to the relevant LEA(s) (based on IAs, if defined);
- to
distribute the intercept
content
of
communicationsproduct to the relevant LEA(s) (based
on IAs, if defined).
For the delivery of the CC and IRI, the 3G MSC Server provides
a correlation number and target identity to the DF2 and DF3 which is used
there
in order to select the different LEAs to which the product shall
be delivered.
NOTE: If interception has been activated for both parties of the call both CC and IRI will be delivered for each party as separate intercept activity.
The Mc interface between the 3G MSC Server and MGW is used to establish intercept and deliver the bearer to DF3.
For Location Dependent Interception, the location dependency check occurs at the establishment of each call. Subsequent dependency checks for simultaneous calls are not required, but can be a national option.
If a target is marked using an IA in the 3G MSC Server, the 3G MSC Server shall perform a location dependency check at call set-up. Only if the target's location matches the IA then the call is intercepted.
If a target is marked using an IA in the DF2, the DF2 shall perform a location dependency check at reception of the first IRI for the call. Only if the target’s location matches the IA for certain LEAs is IRI the relayed to these LEAs. All subsequent IRIs for the call are sent to the same LEAs.
If a target is marked using an IA in the DF3, the DF3 signalling function shall perform a location dependency check at reception of the CC. Only if the target’s location matches the IA for certain LEAs is the CC relayed to these LEAs.
*****************NEXT
CHANGE*****************
6.1 Provision of Intercept CC - Circuit Switched
Figure 12 shows the access method for the delivering of CC. The access method shall be a bridged/ T-connection.
Figure 12: Delivery configuration to the LEMF for the interception of a circuit switched call
The signals of both parties of the configuration to be intercepted are delivered separately to the LEMF. The delivery function has no impact on the connection between the subscribers.
The two stublines towards the LEMF are established in parallel to the call set up. For both stublines the address is used which has been provided during activation.
Bearer, and only bearer, is sent from the MGW to the bearer function of DF3.
NOTE: For data calls it is necessary to provide means for fast call establishment towards the LEMF to help ensure that the beginning of the data transmission is delivered.
The following
information needs to be transferred from the 3G MSC Server
(to
be confirmed by SA WG3 LI group) to the DF3 in order to
allow the DF3 to perform its functionality:
- target identity (MSISDN, IMSI or IMEI); note 1
- the target location (if available) or the IAs in case of location dependent interception. note 1
- correlation number (IRI <-> CC);
- direction indication - (Signal from target or signal to target).
NOTE 1: For DF3 internal use only.
Additional information may be provided if required by national laws.
*****************NEXT
CHANGE*****************
7.1 Provision of Intercept Product - Short Message Service
Figure 19 shows an SMS transfer from the 3G SGSN node to the LEA. Quasi-parallel to the delivery from / to the mobile subscriber a SMS event, which contains the content and header of the SMS, is generated and sent via the Delivery Function 2P to the LEA in the same way as the Intercept Related Information. National regulations and warrant type determine if a SMS event shall contain only SMS header, or SMS header and SMS content.
The IRI will be delivered to the LEA:
- for a SMS-MO. Dependent on national requirements, delivery shall occur either when the 3G SGSN receives the SMS from the target MS or when the 3G SGSN receives notification that the SMS-Centre successfully received the SMS;
- for a SMS-MT. Dependent on national requirements, delivery shall occur either when the 3G SGSN receives the SMS from the SMS-Centre or when the 3G SGSN receives notification that the target MS successfully received the SMS.
Figure 19: Provision of Intercept Product - Short Message
Service
7.2 Provision of Intercepted Content of Communications – Packet data GSN services
The access method for the delivering of Packet Data GSN
Intercept Product is based on duplication of packets without modification
at 3G GSN. The duplicated packets with additional information in
thea
header, as described in
the7.2.1
following
clauses, are sent to
DF3P
for further delivery
via
a
tunnelto
the LEA.
Figure 20: Configuration for interception of Packet Data GSN product data
7.2.1 X3-interface
In addition to the intercepted content of communications, the following information needs to be transferred from the 3G GSN to the DF3P in order to allow the DF3P to perform its functionality:
- target identity;
- correlation number;
- time stamp - optional;
- direction (indicates whether T-PDU is MO or MT) - optional;
- the target location (if available) or the IAs in case of location dependent interception.
As a national option, in the case where the 3G GGSN is performing interception of the content of communications, the intercept subject is handed off to another SGSN and the same 3G GGSN continues to handle the content of communications subject to roaming agreements, the 3G GGSN shall continue to perform the interception of the content of communication.
*****************NEXT
CHANGE*****************
7.3.2 Structure of the events
There are several different events in which the information is sent to the DF2 if this is required. Details are described in the following clause. The events for interception are configurable (if they are sent to DF2) in the 3G GSN or the HLR and can be suppressed in the DF2.
The following events
are applicable to 3G SGSN:
- Mobile Station Attach;
- Mobile Station Detach;
- PDP context activation;
- Start of interception with mobile station attached (national option);
- Start of intercept with PDP context active;
- PDP context modification;
- PDP context deactivation;
- RA update;
- SMS.
NOTE: 3G GGSN interception is a national option. Location information may not be available in this case.
The following events are applicable to the 3G
GGSN:
- PDP context
activation;
- PDP context
modification;
- PDP context deactivation;
- Start of interception with PDP context active.
The following events are applicable to the
HLR:
- Serving System.
A set of
fields
elements
as shown below can be associated with the events. The events
trigger the transmission of the information from 3G GSN or HLR to DF2. Available
IEs from this set of
fields
elements
as shown below can be extended in the 3G GSN or HLR, if this
is necessary as a national option. DF2 can extend available information if
this is necessary as a national option e.g. a unique number for each surveillance
warrant.
Table 2: Information Events for Packet Data Event Records
Observed MSISDN MSISDN of the target subscriber (monitored subscriber). |
Observed IMSI IMSI of the target subscriber (monitored subscriber). |
Observed IMEI IMEI of the target subscriber (monitored subscriber),it shall be checked for each activation over the radio interface. |
Event type Description which type of event is delivered: MS attach, MS detach, PDP context activation, Start of intercept with PDP context active, PDP context deactivation, SMS, Serving System, Cell and/or RA update. |
Event date Date of the event generation in the 3G GSN or the HLR. |
Event time Time of the event generation in the 3G GSN or the HLR. Timestamp shall be generated relative to GSN or HLR internal clock. |
PDP address The PDP address of the target subscriber. Note that this address might be dynamic. |
Access Point Name The APN of the access point. (Typically the GGSN of the other party). |
Location Information Location Information is the Service Area Identity (SAI), RAI and/or location area identity that is present at the GSN at the time of event record production. |
Old Location Information Location Information of the subscriber before Routing Area Update |
PDP Type The used PDP type. |
Correlation Number The correlation number is used to correlate CC and IRI. |
SMS The SMS content with header which is sent with the SMS-service. The header also includes the SMS-Centre address. |
Network Element Identifier Unique identifier for the element reporting the ICE. |
Failed attach reason Reason for failed attach of the target subscriber. |
Failed context activation reason Reason for failed context activation of the target subscriber. |
IAs The observed Interception Areas. |
Initiator The initiator of the PDP context activation, deactivation or modification request either the network or the 3G MS. |
SMS Initiator SMS indicator whether the SMS is MO or MT. |
Deactivation / termination cause The termination cause of the PDP context. |
QoS This field indicates the Quality of Service associated with the PDP Context procedure. |
Serving System Address Information about the serving system (e.g. serving SGSN number or serving SGSN address). |
7.4 Packet Data related events
7.4.1 Mobile Station Attach
For attach an attach-event is generated. When an attach
activation is generated from the mobile to
servicing
3G G SN this event is generated. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Location Information |
Failed attach reason |
IAs (if applicable) |
7.4.2 Mobile Station Detach
For detach a detach-event is generated, this is for the
common (end) detach. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Location Information |
IAs (if applicable) |
7.4.3 Packet Data PDP context activation
For
PDP context activation a PDP context activation-event is generated.
When a PDP context activation is generated
from
the mobile to 3G GSN
a
PDP context
activation-eventthis event is generated. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
PDP address of observed party |
Event Type |
Event Time |
Event Date |
Correlation number |
Access Point Name |
PDP Type |
Network Element Identifier |
Location Information |
Failed context activation reason |
IAs (if applicable) |
Initiator (optional) |
QoS (optional) |
7.4.4 Start of interception with PDP context active
This event will be generated if interception for a target
is started and if the target has at least one PDP context active. If more
then one PDP context are
open,
for each of them an event record is generated. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
PDP address of observed party |
Event Type |
Event Time |
Event Date |
Correlation number |
Access Point Name |
PDP Type |
Network Element Identifier |
Location Information |
Old Location Information (optional) |
IAs (if applicable) |
QoS (optional) |
Initiator (optional) |
Presence of the optional Old Location Information field indicates that PDP context was already active, and being intercepted. However, the absence of this information does not imply that interception has not started in the old location SGSN for an active PDP context.
Start of interception with PDP context active shall be sent regardless of whether a Start of interception with mobile station attached has already been sent.
7.4.5 Packet Data PDP context deactivation
At PDP context deactivation a PDP context deactivation-event
is generated. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
PDP address of observed party |
Event Type |
Event Time |
Event Date |
Correlation number |
Access point name |
Network Element Identifier |
Location Information |
IAs (if applicable) |
Deactivation cause |
Initiator (optional) |
7.4.6 RA update
For each RA update an update-event with the
fields
elements
about the new location is generated. New SGSN shall send the
event, and the old SGSN may optionally send the event as well. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Location Information (only for the new SGSN) |
Old Location Information (only for the old SGSN) |
IAs (if applicable) |
NOTE: Once target moves out of the interception area, old SGSN may report the RAU event. Normally, however, the old SGSN does not receive the new SGSN’s RAI, while the new SGSN does receive the old SGSN’s RAI from UE with the RAU Request message.
7.4.7 SMS
For MO-SMS the event is generated in the 3G SGSN. Dependent
on national requirements, event generation shall occur either when the 3G
SGSN receives the SMS from the target MS or when the 3G SGSN receives
notification that the SMS-Centre successfully receives the SMS; for MT-SMS
the event is generated in the 3G SGSN. Dependent on national requirements,
event generation shall occur either when the 3G SGSN receives the SMS from
the SMS-Centre or when the 3G SGSN receives notification that the target
MS successfully received the message. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Location Information |
SMS |
SMS Initiator |
IAs (if applicable) |
7.4.8 Packet Data PDP context modification
This event will be generated if interception for a target
is started and if the target has at least one PDP context active. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
PDP address of observed party |
Event Type |
Event Time |
Event Date |
Correlation number |
Access Point Name |
PDP Type |
Network Element Identifier |
Location Information |
IAs (if applicable) |
Initiator |
QoS |
7.4.9 Serving System
The Serving System report event is generated at the HLR,
when the HLR has detected that the intercept subject has roamed. The
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Serving System Address |
7.4.10 Start of interception with mobile station attached
This event will be generated if interception has started
for the already attached target. These
fields
elements
will be delivered to the DF2 if available:
Observed MSISDN |
Observed IMSI |
Observed IMEI |
Event Type |
Event Time |
Event Date |
Network Element Identifier |
Location Information |
IAs (if applicable) |
*****************NEXT
CHANGE*****************
8.5.2 Data consistency
The administration function in the 3GPP MS shall be capable
to
of
performing
a periodic consistency check to ensure that the target list of target identities
in all involved 3G MSC Servers, CSCFs, 3G GSNs in the 3GPP MS and the DFs
contain the appropriate target Ids consistent with the intercept orders in
the ADMF. The reference data base is the ADMF data base.
*****************END OF CHANGE
*****************